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BUS PERFORMANCE EVALUATION METHOD 
FOR ALGORITHM DESCRIPTION 

BACKGROUND OF THE INVENTION 

5 Field of the Invention 

This invention is provided for verification of algorithms in order to facilitate 

architecture designs at high-level stages of design. Specifically, this invention relates 

to bus performance evaluation methods for algorithm descriptions in which evaluation 

is performed on performances of buses interconnecting between the hardware and 
10 software by use of sources described by general purpose high-level languages such as 

the C language and C++ language. 

Description of the Related Art 

Due to the recent developments of the semiconductor technologies, there are 

tendencies for the physical hardware system to be frequently actualized by a single LSI 
15 chip rather than by plural LSI chips arranged on boards. For this reason, signals of 

the LSI chips that are conventionally interconnected with external terminals are 

translated to internal signals and are incorporated within the LSI chips in these days. 

To verify the conventional systems using the boards, it is necessary to produce LSI 

devices specifically for use in evaluation that is performed as if all internal signals are 
20 interconnected with external terminals. However, it is troublesome for manufacturers 

to perform verification on the systems by using the specifically designed LSI devices. 

Actually, the recent developments raise a difficulty in which verification is difficult to 

perform using the foregoing boards. 

FIG. 11 shows a flow of steps showing the conventional procedures for the 
25 design and development of LSI (hereinafter, simply referred to as LSI design and 
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development) in manufacture of logic circuits, systems and devices. Prior to the 
actual manufacturing, simulation platforms (or algorithms) are normally structured 
without consideration of distinctions between the hardware and software (see step Bl). 
In step B2, verification is made as to whether the algorithms are correctly made or not. 
5 Next, isolation of the hardware and software is performed on the structured simulation 
platforms, which are divided into hardware elements and software elements 
respectively. The isolation of the hardware and software is made by experiments. 

In the hardware design (or H/W design), sources having equivalent functions 
of the algorithms are generally described by HDL (which stands for 'Hardware 

10 Description Language 5 ), then, composition of circuitry is carried out (see step B3). 

In step B4, verification is made as to whether the sources operate normally or not. In 
the software design (or S/W design), sources having equivalent functions of the 
algorithms are generally described by the programming language having a CPU 
dependency (see step B5). In step B6, verification is made as to whether the sources 

15 operate normally or not. Lastly, cooperative verification is performed on 
combinations of the hardware and software (see step B7). 

Prior to the actual manufacturing of LSI, the procedures for the LSI design 
and development should meet some essential conditions raising requirements of the 
system simulation and bus performance evaluation as well as the architecture design in 

20 which isolation of the hardware and software is performed by simulation. 

Conventionally, the system simulation is performed by the cooperative verification on 
the unification of the hardware and software. 

Due to rapid increases in scales of integrated circuits being manufactured in 
these days, it becomes necessary to provide considerably large numbers of codes for 

25 use in description of the circuits to be created. This causes considerable reduction in 
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simulation speed of the cooperative verification on descriptions using the HDL or 
other programming languages each having a CPU dependency. In practice, it 
becomes very difficult to perform the architecture design using the cooperative 
verification. 

5 In the architecture design using the cooperative verification, there may occur 

necessities of modifications on buses interconnecting between the hardware and 
software due to results of evaluation of performances of the buses. In that case, it is 
necessary to modify the HDL or other programming languages each having a CPU 
dependency (see steps B8, B9 in FIG. 11). 

10 Due to increasing numbers of codes for use in description of the circuits to be 

created, circuit descriptions must become more and more complicated, which in turn 
cause complicity in modifications of the circuit descriptions. That is, it takes much 
time and cost to perform operations regarding feedback loops being derived from 
results of the cooperative verification. Recently, there are tendencies in which 

15 periods for developments of LSI are considerably reduced while the circuit scales are 
increased more and more. To cope with such tendencies, the procedures of the LSI 
design and development should meet some essential conditions in which evaluation of 
performances of the buses interconnecting between the hardware and software and the 
architecture design are performed at high-level stages of design respectively. 

20 

SUMMARY OF THE INVENTION 
It is an object of the invention to provide a bus performance evaluation 
method for algorithm description by which it is possible to considerably reduce 
turnaround times in design of LSI by excluding unwanted operations regarding 
25 feedback loops derived from cooperative verification in the hardware design and 
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software design. Basically, this invention provides improvements in procedures for 
the design and development of LSI. That is, after isolation of the hardware and 
software being effected with respect to sources described by the general purpose high- 
level language in algorithm design, an evaluation function is created to count traffic of 
5 the bus interconnecting between the hardware and software. The sources are 
modified such that the evaluation function is performed every time data (e.g., a 
variable) is loaded onto the bus. Then, evaluation is performed on the performance of 
the bus having a processing rate. Based on the bus traffic that is finally produced 
with respect to the processing rate, isolation of the hardware and software is optimally 

1 0 performed at the prescribed stage of the architecture design. Thus, it is possible to 
exclude the feedback loops regarding the isolation between the hardware and software 
from the cooperative verification after the actual coding. As a result, it is possible to 
considerably reduce the turnaround time in the design of LSI. 

More specifically, the LSI design and development in manufacture is 

1 5 actualized by algorithm design, architecture design, actual hardware and software 
design, and verification. Herein, the architecture design contains a simulation 
platform structuring process and a bus performance evaluation process, which are 
interconnected by a feedback loop. In the algorithm design, sources are described by 
the general purpose high-level language such as the C language and C++ language. 

20 In the simulation platform structuring process, the sources are subjected to isolation of 
the hardware and software, while an evaluation function is created to count bus traffic 
of the bus interconnecting between the hardware and software. Every time data is 
written to a pre-defined variable loaded onto the bus, the evaluation function is 
performed to modify the sources. Then, evaluation is performed on the performance 

25 of the bus, so that the bus traffic for its processing rate is finally produced. That is, 
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result of the bus performance evaluation process is fed back to the simulation platform 
structuring process such that isolation of the hardware and software is optimized in 
response to the bus traffic for the processing rate of the bus. This results in exclusion 
of feedback loops derived from the cooperative verification after the actual coding, so 
5 it is possible to considerably reduce overall turnaround time of design. 

BRIEF DESCRIPTION OF THE DRAWINGS 
These and other objects, aspects and embodiments of the present invention 
will be described in more detail with reference to the following drawing figures, of 
10 which: 

FIG. 1 is a flowchart showing procedures for design and development of LSI 
in accordance with the invention; 

FIG. 2 shows a list form representing a bus performance evaluation method in 
accordance with a first embodiment of the invention; 
15 FIG. 3 shows a list form representing a simulation platform that is 

restructured in accordance with the first embodiment shown in FIG. 2; 

FIG. 4 is a flowchart showing procedures of works that are effected by the 
first embodiment shown in FIG. 2; 

FIG. 5 shows a list form representing a bus performance evaluation method in 
20 accordance with a second embodiment of the invention; 

FIG. 6 shows a list form representing a bus performance evaluation method in 
accordance with a third embodiment of the invention; 

FIG. 7 shows a list form representing a bus performance evaluation method in 
accordance with a fourth embodiment of the invention; 
25 FIG. 8 shows a list form representing a bus performance evaluation method in 



accordance with a fifth embodiment of the invention; 

FIG. 9 shows a list form representing a bus performance evaluation method in 
accordance with a sixth embodiment of the invention; 

FIG. 10 shows a list form representing a simulation platform that is structured 
5 using sources described by the C++ language; and 

FIG 1 1 is a flowchart showing procedures for the conventional design and 
development of LSI- 
DESCRIPTION OF THE PREFERRED EMBODIMENTS 
1 0 This invention will be described in further detail by way of examples with 

reference to the accompanying drawings. 

FIG. 1 shows a flow of procedures for design and development of LSI in 
accordance with the invention. As compared with the conventional flow of 
procedures for the LSI design and development that is described in conjunction with 
1 5 FIG. 1 1 3 the present flow shown in FIG. 1 is facilitated in manufacture to enable the 
architecture design at the high-level stage of design and is characterized by adding a 
simulation platform structuring process and a bus performance evaluation process (see 
step Al 5). Details of these processes will be described below. 

In step Al, algorithms are designed for logic circuits, devices and systems to 
20 be manufactured. In step A2, verification is made as to whether the algorithms are 
made correctly or not. 

Next, a simulation platform is structured to perform architecture design by 
using sources, which are used in the aforementioned algorithm design. Namely, in 
the simulation platform structuring process, the flow proceeds to step A3 to effect 
25 isolation of the hardware and software. In step A4, an evaluation function is created. 
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Herein, it is satisfactory that the evaluation function has an operation of counting a 
certain value. 

In step A5, variables loaded onto the bus interconnecting between the 
hardware and software are being selected. Then, the flow proceeds to step A6 in 
5 which sources that are used in the algorithm design are modified by executing the 
created evaluation function when data are written to the variables loaded onto the bus, 
in other words, when data transfer is effected on the bus that is a subject of evaluation 
(hereinafter, simply referred to as the 'evaluated' bus). In response to modifications 
of the sources, the simulation platform for use in the architecture design is structured 
10 again. 

Next, evaluation is performed on the performance of the bus, which is a 
subject of evaluation, by using the structured simulation platform. That is, in the 
performance evaluation process, the flow proceeds to step A7 in which verification is 
performed using the structured simulation platform. In step A8, bus traffic is 
15 calculated by the prescribed method, which depends on the created evaluation function. 
Herein, a processing rate requested by a main function is already known. Hence, the 
bus traffic is calculated with respect to the processing rate of the evaluated bus in step 
A9. 

Using the bus traffic that is calculated in response to the processing rate, it is 
20 possible to check validity with respect to isolation of the hardware and software and a 
bus configuration. If the validity check causes a change of the bus, the sources that 
are described by the general purpose high-level language such as the C language and 
C++ language are modified, then, the simulation platform is structured again and the 
performance evaluation is performed again. That is, the present procedures provide a 
25 feedback loop (see step A16) for feeding back the result of the performance evaluation 
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of the bus. Due to provision of such a feedback loop, it is possible to actualize the 
architecture design at the high-level stage of design. 

After completion of the architecture design in step A15, the flow proceeds to 
the hardware design (H/W design) and the software design (S/W design) respectively. 
5 In the hardware design, sources having equivalent functions of the algorithm(s) are 
generally described by the HDL (i.e,, Hardware Description Language), then, 
composition of circuitry is performed in step A10. In step All, verification is made 
as to whether the sources operate normally or not. In the software design, sources 
having equivalent functions of the algorithm(s) are generally described by the 

10 programming language having a CPU dependency in step A12. In step A13, 
verification is made as to whether the sources operate normally or not. 

In step A14, cooperative verification is performed on unification of the 
hardware and software. In the present flow of procedures for the design and 
development of LSI, the architecture design is already completed at the high-level 

1 5 stage of design. This places the cooperative verification as one type of simulation for 
making operational confirmation only, in which no design is newly made. Namely, 
this eliminates the necessity to provide feedback loops being derived from the 
cooperative verification. 

FIG. 2 shows a list form representing a bus performance evaluation method in 

20 accordance with the first embodiment of the invention. With reference to FIG. 2, 
there are provided three variables, namely c a\ c b' and V being loaded onto the 
evaluated bus, wherein all of the variables are subjected to global definition. In 
addition, there are provided an evaluation function 'BUSOO' and a local variable 
c bus0\ Herein, the evaluation function increments a static variable i to provide a 

25 return value. The local variable busO stores the return value from the evaluation 
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function BUSOO- Namely, it represents a number of times in effecting data transfer 
on the evaluated bus. The same number of bits are set to binary representations of the 
three variables a, b, c being loaded onto the evaluated bus. Herein, the number of bits 
of each variable is smaller than the number of lines (or bits) of the evaluated bus. 
5 The first embodiment shown in FIG. 2 is designed to certainly execute the 

evaluation function BUS0() when data are written to the variables a, b, c loaded onto 
the evaluated bus. So, the evaluation function BUSOO is embedded subsequent to (or 
just after) the variables to which data are written respectively. Every time the 
evaluation function BUSOO is executed, the static variable i is incremented to provide 

10 a return value. The return value from the evaluation function BUSOO represents the 
number of times in writing data to the variables loaded onto the evaluated bus. 

In addition, the number of times in writing the data to the variables loaded 
onto the evaluated bus represents a number of times in effecting data transfer on the 
evaluated bus, namely bus traffic. Because the processing rate requested by the main 

15 function is already known, it is possible to calculate the bus traffic for the processing 
rate and effect performance evaluation in accordance with the following equation (1). 
(Bus traffic for the processing rate) 

= (number of times in effecting data transfer) / (processing rate) ... (1) 
To change the bus interconnecting between the hardware and software in response to 

20 the bus traffic being calculated for the processing rate, the sources used in the 

algorithm design are modified so that the simulation platform is to be structured again. 

FIG. 3 shows an example of the 'restructured' simulation platform. With 
reference to the restructured simulation platform shown in FIG. 3, the variable b is 
regarded as one that is not to be loaded onto the evaluated bus because of result of the 

25 performance evaluation of the bus. That is, the restructured simulation platform has 
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only two variables a, b that are being loaded onto the evaluated bus. Since the 
variable b is not loaded onto the bus, the evaluation function BUS0() is not embedded 
subsequent to the variable b to which data is written. In contrast, the evaluation 
function BUS00 is certainly embedded subsequent to the variables a, c to which data 
5 are written respectively. Thus, the evaluation function BUS0() is certainly executed 
just after the variables a, c to which the data are written respectively. 

After restructuring of the simulation platform, verification is performed by 
simulation. Then, the bus traffic for the processing rate is calculated again in 
accordance with the equation (1), so that evaluation is to be performed on the 
1 0 performance of the bus. 

Through the aforementioned operations, an average bus traffic is produced 
with respect to the data rate of the evaluated bus. Then, performance evaluation is 
performed on the bus, so that the result of the performance evaluation is fed back to 
structuring of the simulation platform. Hence, it is possible to actualize the 
15 architecture design at the high-level stage of design. 

FIG. 4 shows a flow of steps that are performed by a computer system 
realizing the aforementioned bus performance evaluation method shown in FIG. 1. 

With reference to FIG. 4, the flow firstly proceeds to step CI in which a 
specific evaluation function is created. It is satisfactory that the evaluation function 
20 meets an operation of incrementing a certain value. Herein, the algorithm design uses 
sources that are described by the C language or C++ language. In step C2, the system 
reads the sources line by line while effecting syntax analysis. 

In step C3, a decision is made as to whether the read sources describe 
operations of writing data to the variables loaded onto the evaluated bus or not. If so, 
25 the flow proceeds to step C4 in which the evaluation function is embedded subsequent 
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to the variables to which the data are written respectively. Due to the aforementioned 
works, the evaluation function is certainly executed when the data are written to the 
variables loaded onto the evaluated bus, in other words, when data transfer is caused 
on the evaluated bus. 

5 In step C5, a decision is made as to whether description of the sources reading 

in the aforementioned works is completed up to the last line of the sources originally 
used in the algorithm design or not. Thus, modification is effected on the sources 
originally used in the algorithm design. After the modification proceeds to the last 
line of the sources used in the algorithm design, the flow proceeds to step C6 in which 
10 the system compiles the modified sources to structure the simulation platform for use 
in the architecture design. In step CI, bus traffic is calculated for the evaluated bus 
by execution of the simulation platform. Because the processing rate requested by 
the main function is already known, the bus traffic for the processing rate is produced 
so that performance evaluation is performed on the evaluated bus in step C8. 
1 5 Figures 5 to 1 0 show examples of list forms representing the bus performance 

evaluation methods in accordance with other embodiments of the invention. Next, 
those embodiments will be described in detail in comparison with the aforementioned 
first embodiment shown in FIG. 2. 

FIG. 5 shows the bus performance evaluation method of the second 
20 embodiment that has tree variables a, b and c, which are loaded on the evaluated bus 
and all of which are locally defined. In addition, there are provided an evaluation 
function BUS00 and a local variable busOO- The evaluation function increments a 
static variable i to provide a return value. The local variable busOO stores the return 
value from the evaluation function BUSOO- That is, it represents a number of times 
25 in effecting data transfer on the evaluated bus. 
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All of the variables a, b and c consist of the same number of bits, which is 
smaller than a number of lines (or bits) of the evaluated bus. A main difference 
between the first embodiment of FIG. 2 and the second embodiment of FIG. 5 lies in 
manners of definition of the variables, that is, the variables loaded onto the evaluated 
5 bus are not defined globally but defined locally in FIG. 5. To perform performance 
evaluation on the bus, bus traffic for its processing rate is calculated in accordance 
with the aforementioned equation (1). 

As the second embodiment is designed such that the variables loaded onto the 
evaluated bus are not defined globally but are defined locally, it proceeds to 
10 calculation of the bus traffic for the processing rate and performance evaluation of the 
bus, then, it feeds back the result of the performance evaluation to structuring of the 
simulation platform. Therefore, as similar to the first embodiment, the second 
embodiment allows the architecture design to be effected at the high-level stage of 
design. 

15 FIG. 6 shows the bus performance evaluation method of the third embodiment 

that has three variables a, b and c, which are loaded onto the evaluated bus and all of 
which are defined globally. In addition, there are provided an evaluation function 
BUS00 and a local variable bus0(). Herein, the evaluation function increments a 
static variable i to provide a return value. The local variable busOO stores the return 

20 value from the evaluation function BUSOO* That is, it represents a number of times 
in effecting data transfer on the evaluated bus. 

All of the variables a, b and c consist of the same number of bits, which is 
smaller than a number of lines (or bits) of the evaluated bus. A main difference 
between the first embodiment of FIG. 2 and the third embodiment of FIG. 6 lies in 

25 manners of embedding of the evaluation function BUSOO, that is, the evaluation 



13 

function is embedded just before the variables to which data are written respectively. 
Thus, the evaluation function is certainly performed when the data are written to the 
variables respectively, in other words, when data transfer is effected on the evaluated 
bus. Incidentally, the third embodiment performs the performance evaluation upon 
5 calculation of the bus traffic for the processing rate by the aforementioned equation 
0). 

As described above, the third embodiment is designed such that the evaluation 
function BUSOO is embedded just before the variables to which data are written 
respectively, in other words, it is designed such that the evaluation function BUSOO is 

10 to be certainly performed when data are written to the variables respectively or when 
data transfer is effected on the evaluated bus. Herein, the third embodiment proceeds 
to calculation of the bus traffic for the processing rate and performance evaluation of 
the bus, then, it feeds back the result of the performance evaluation to structuring of 
the simulation platform. Therefore, as similar to the first embodiment, the third 

15 embodiment allows the architecture design to be effected at the high-level stage of 
design. 

Next, a description will be given with respect to the case where all of the 
variables a, b and c have the same number of bits, which is greater than the number of 
lines (or bits) of the evaluated bus. The description will be given with respect to the 
20 case where each of the variables a, b and c consists of n bits while the evaluated bus 
consists of m bits (where n^m). For example, n is set to { 32\ and 'm' is set to *8\ 

In the aforementioned case, when data are written to the variables loaded onto 
the evaluated bus, data transfer is effected on the bus multiple times, a number of 
which is calculated by 'n/m\ that is, four times. To perform the performance 
25 evaluation on the bus, bus traffic for its processing rate is calculated by the following 
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equation (2). 

(Bus traffic for the processing rate) 

= (number of times in execution) X 4 / (processing rate) ... (2) 
Next, further embodiments of the invention will be described with reference 
5 to Figures 7 to 10, 

FIG. 7 shows the bus performance evaluation method of the fourth 
embodiment that has two variables a, b loaded onto the evaluated bus, wherein both of 
the variables are defined globally. In addition, there are provided an evaluation 
function BUS 1 0 and a local variable bus 1 . Herein, the evaluation function BUS 10 
10 has two arguments, namely 'bit' and 'bus'. That is, it increments a static variable i by 
'bit/bus' to provide a return value. The local variable busl stores the return value 
from the evaluation function BUS 10- That is, it represents a number of times in 
effecting data transfer on the evaluated bus. 

Suppose that the variable a loaded onto the evaluated bus consists of thirty- 
15 two bits while the variable b loaded onto the evaluated bus consists of sixteen bits, 
wherein the evaluated bus consists of eight bits. 

Different from the foregoing first embodiment of FIG. 2, the fourth 
embodiment of FIG. 7 deals with two bits loaded onto the evaluated bus, wherein the 
two variables are configured by different numbers of bits, both of which are greater 
20 than the number of bits of the evaluated bus. In addition, the fourth embodiment of 
FIG. 7 is characterized by that the evaluation function having two arguments 'bit' and 
'bus', and it increments the static variable i to provide a return value. To perform 
performance evaluation on the bus, bus traffic for its processing rate is calculated by 
the aforementioned equation (1). 
25 Although the fourth embodiment is designed such that the variables loaded 
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onto the evaluated bus are configured by different numbers of bits, which are greater 
than the number of bits of the evaluated bus, it proceeds to calculation of the bus 
traffic for the processing rate and performance evaluation of the bus, then, it feeds 
back the result of the performance evaluation to structuring of the simulation platform. 
5 Therefore, as similar to the first embodiment, the fourth embodiment allows the 
architecture design to be effected at the high-level stage of design. 

FIG. 8 shows the bus performance evaluation method of the fifth embodiment 
that has two variables a, b loaded onto the evaluated bus, which are defined by specific 
arrays respectively In addition, there are provided an evaluation function BUSOO 

10 and a local variable bus2. Herein, the evaluation function has an argument c ele ? , so it 
increments a static variable i by c ele* to provide a return value. The local variable 
bus2 stores the return value from the evaluation function BUS20, so it represents a 
number of times in effecting data transfer on the evaluated bus. 

Both of the variables a, b loaded onto the evaluated bus consist of the same 

15 number of bits, which is smaller than a number of bits of the evaluated bus. Different 
from the first embodiment of FIG. 2, the fifth embodiment of FIG. 8 is designed such 
that both of the variables loaded onto the evaluated bus are defined by specific arrays, 
and address transfer is effected in the main function. In addition, the fifth 
embodiment is characterized by that the evaluation function having an argument 'ele' 

20 increments the static variable i by *ele' to provide a return value. 

To perform performance evaluation on the bus, bus traffic for its processing 
rate is calculated by the aforementioned equation (1). 

Although the fifth embodiment is designed such that the variables loaded onto 
the evaluated bus are defined by the specific arrays, and the address transfer is effected 

25 in the main function, the fifth embodiment proceeds to calculation of the bus traffic for 
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the processing rate and performance evaluation of the bus, then, it feeds back the result 
of the performance evaluation to structuring of the simulation platform. Therefore, as 
similar to the first embodiment, the fifth embodiment allows the architecture design to 
be effected at the high-level stage of design. 
5 FIG. 9 shows the bus performance evaluation method of the sixth embodiment 

that has two variables a, b loaded onto the evaluated bus, wherein the variables are 
both defined globally. In addition, there are provided an evaluation function BUS30 
and a global variable 'bus 5 . The evaluation function increments the global variable 
'bus 3 . The global variable 'bus' represents a number of times in effecting data 

10 transfer on the evaluated bus. 

Both of the variables a, b consist of the same number of bits, which is smaller 
than a number of bits of the evaluated bus. Different from the first embodiment of 
FIG. 1, the sixth embodiment of FIG. 9 is characterized by that the variables to be 
incremented by the evaluation function are defined globally. 

15 To perform performance evaluation on the bus, bus traffic for its processing 

rate is calculated by the foregoing equation (1). 

Although the sixth embodiment is designed such that the variables to be 
incremented by the evaluation function are defined globally, the sixth embodiment 
proceeds to calculation of the bus traffic for the processing rate and performance 

20 evaluation of the bus, then, it feeds back the result of the performance evaluation to 
structuring of the simulation platform. Therefore, as similar to the first embodiment, 
the sixth embodiment allows the architecture design to be effected at the high-level 
stage of design. 

FIG. 10 shows an example of a simulation platform that is structured by 
25 sources described by the C++ language. 
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In the simulation platform shown in FIG. 10, there are provided three buses, 
namely <bus0\ 'busl' and 'bus2' which are subjected to BUS class definition as well 
as three variables a, b and c. Herein, the variable a is defined globally and is loaded 
onto the bus busCL The variable b is defined locally and is loaded onto the bus busl . 
The variable c is defined by a specific array and is loaded onto the bus bus2. 

There is provided a BUS class, which has a function 'countO' for 
incrementing a member variable i by 4 V as well as two arguments, namely 'bit' and 
'bus'. In addition, there are provided a function 'CountbitO' for incrementing the 
member variable i by 'bit/bus' and an argument 'ele\ Further, a function 
'countJiairetuO' for incrementing the member variable i by 'ele' is defined. 
Therefore, the member variable i within the BUS class represents a number of times in 
effecting data transfer on the evaluated bus. 

Both of the variables a, c loaded onto the evaluated bus consists of the same 
number of bits, which is smaller than numbers of bits of the buses busO and busl 
respectively. In addition, the variable b loaded onto the evaluated bus consists of 
thirty-two bits, while the bus busl consists of eight bits. 

Different from the foregoing embodiments (including the first embodiment of 
FIG. 2), the simulation platform of FIG. 10 is characterized by the sources being 
described by the C++ language. To perform performance evaluation on the bus, bus 
traffic for its processing rate is calculated by the aforementioned equation (1). 

Although the simulation platform is structured using the sources described by 
the C++ language as shown in FIG. 10, it proceeds to calculation of the bus traffic for 
the processing rate and performance evaluation of the bus, then, it feeds back the result 
of the performance evaluation to restructuring of the simulation platform. Therefore, 
it is possible to carry out the architecture design at the high-level stage of design. 
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As described heretofore, this invention is designed such that when data 
transfer is caused on the bus interconnecting between the hardware and software to be 
evaluated, the sources that are used in the architecture design and are described by the 
general purpose high-level language such as the C language and C++ language are 
5 modified by executing the specific evaluation function, so that the simulation platform 
for use in the architecture design is structured. Then, simulation is performed using 
the structured simulation platform to calculate the bus traffic for the processing rate of 
the evaluated bus. Thus, it is possible to perform the bus performance evaluation at 
the high-level stage of design. 
10 Result of the bus performance evaluation is fed back to the sources that are 

used in verification of the algorithm(s). This enables the architecture design to be 
performed at the high-level stage of design. So, it is possible to reduce overall 
simulation time that is necessary for the architecture design. In addition, this 
invention is characterized by placing the cooperative verification on the unification of 
15 the hardware and software as one type of simulation that merely performs operational 
confirmation. That is, it is possible to exclude actual designing steps from the 
cooperative verification, so it is possible to considerably reduce the time and cost that 
are needed for design and development of the logic circuits, systems and devices. 

As described heretofore, this invention has a variety of effects and technical 
20 features, which will be described below. 

(1) When data are written to variables loaded onto the evaluated bus, sources that are 
described by the general purpose high-level language such as the C language and 
C++ language for use in the algorithm design are modified by executing a specific 
evaluation function for increment by a certain value, so that a simulation platform 
25 is structured. Hence, bus traffic is calculated in connection with the processing 
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rate of the bus interconnecting between the hardware and software, so bus 
performance evaluation can be performed at the high-level stage of design in the 
LSI design and development. In addition, result of performance evaluation of the 
bus is fed back to structuring of the simulation platform, so it is possible to perform 
5 the architecture design at the high-level stage of design. Because the architecture 
design is performed using the sources that are described by the general purpose 
high-level language for use in the algorithm design, it is possible to considerably 
reduce overall simulation time for the architecture design. Generally speaking, as 
compared with the HDL, the C language and C++ language are increased in 
10 simulation speed to be approximately one-thousand times higher. 

(2) Because the architecture design is performed using the sources that are described 
by the general purpose high-level language, it is possible to simplify feedback 
procedures due to the architecture design. By optimally performing isolation of 
the hardware and software at the prescribed stage of the architecture design, it is 

15 possible to exclude feedback loops regarding the isolation of the hardware and 
software from the cooperative verification after the actual coding. This 
guarantees considerable reduction of the turnaround time of design. As compared 
with the HDL and other assembly languages, the C language and C++ language can 
be described using a relatively small number of codes. That is, those languages 

20 can be easily changed and modified according to needs. 

(3) This invention places the cooperative verification on unification of the hardware 
and software as one type of simulation for merely performing operational 
confirmation, wherein no design is newly performed. This brings exclusion of the 
feedback loops being derived from the cooperative verification. That is, it is 

25 possible to reduce a number of times in effecting simulation in RTL, so it is 
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possible to considerably reduce overall time and cost for the design of circuitry. 
Such an effect becomes substantial as the scale of circuitry being manufactured 
increases. 

As this invention may be embodied in several forms without departing from 
5 the spirit of essential characteristics thereof, the present embodiments are therefore 
illustrative and not restrictive, since the scope of the invention is defined by the 
appended claims rather than by the description preceding them, and all changes that 
fall within metes and bounds of the claims, or equivalence of such metes and bounds 
are therefore intended to be embraced by the claims. 



